2020年末冲刺 | 大厂面试题-数据仓库

姊妹篇：面试真经 | 大数据/数仓面试灵魂30问（附答案 | 已斩offer）

冬天到了，春天还会远吗？

Version	Desc
2020-09-07	1~10题
2020-10-01	解答14～28&新增19～31题&调整排版

1.手写"连续活跃登陆"等类似场景的sql

 1# 该题目有不同的解法，可以使用row_number窗口函数或者使用lag函数
 2#  第一种解决方案，使用lag(向前)或者lead(向后)
 3select
 4  *
 5from 
 6(
 7  select 
 8    user_id,
 9    date_id,
10    lead(date_id) over(partition by user_id order by date_id) as last_date_id
11  from 
12  (
13    select 
14      user_id,
15      date_id
16    from wedw_dw.tmp_log
17    where date_id>='2020-08-10'
18      and user_id is not null  
19      and length(user_id)>0
20    group by user_id,date_id
21    order by user_id,date_id
22  )t
23)t1
24where datediff(last_date_id,date_id)=1
25-- 第二种解决方案,使用row_number
26select 
27  user_id,
28  min(date_id),
29  max(date_id),
30  count(1)
31from 
32(
33  select
34  t1.user_id
35  ,t1.date_id
36  ,date_sub(t1.date_id,rn) as dis
37  from 
38  (
39    select 
40      user_id,
41      date_id,
42      row_number() over(partition by user_id order by date_id asc) rn
43    from 
44    (
45      select 
46        user_id,
47        date_id
48      from wedw_dw.tmp_log
49      where date_id>='2020-08-10'
50        and user_id is not null  
51        and length(user_id)>0
52      group by user_id,date_id
53      order by user_id,date_id
54    )t
55  )t1
56)t2
57group by user_id,dis 
58having count(1)>2

2.left semi join和left join区别

left semi join 左半连接

in(keySet)，相当于在右表中查询左表的key， left semi join 是 in(keySet) 的关系，遇到右表重复记录，左表会跳过；当右表不存在的时候，左表数据不会显示; 相当于SQL的in语句.比如测试的语句相当于

1select * from table1 where table1.student_no in (table2.student_no)

注意，结果中是没有B表的字段的.LEFT SEMI JOIN 是 IN/EXISTS 子查询的一种更高效的实现;Hive 当前没有实现 IN/EXISTS 子查询，所以你可以用 LEFT SEMI JOIN 重写你的子查询语句。LEFT SEMI JOIN 的限制是， JOIN 子句中右边的表只能在 ON 子句中设置过滤条件，在 WHERE 子句、SELECT 子句或其他地方过滤都不行

left join

当右表不存在的时候，则会显示NULL

 1select * from table1 left semi join table2 on(table1.student_no=table2.student_no);
 2结果：
 31 name1
 42 name2
 53 name3
 64 name4
 75 name5
 8
 9select * from table1 left outer join table2 on(table1.student_no=table2.student_no);
10结果：
111 name1 1 11
121 name1 1 12
131 name1 1 13
142 name2 2 11
152 name2 2 14
163 name3 3 15
173 name3 3 12
184 name4 4 13
194 name4 4 12
205 name5 5 14
215 name5 5 16
226 name6 NULL NULL

3.维度建模和范式建模的区别

通常数据建模有以下几个流程：

1. 概念建模：即通常先将业务划分多个主题

2. 逻辑建模：即定义各种实体、属性和关系

3. 物理建模：设计数据对象的物理实现，比如表字段类型、命名等。

那么范式建模，即3NF模型具有以下特点：

1. 原子性，即数据不可分割

2. 基于第一个条件，实体属性完全依赖于主键，不能存在仅依赖主关键字一部分属性。即不能存在部分依赖

3. 基于第二个条件，任何非主属性不依赖于其他非主属性。即消除传递依赖.

基于以上三个特点，3NF的最终目的就是为了降低数据冗余，保障数据一致性；同时也有了数据关联逻辑复杂的缺点。

而维度建模是面向分析场景的，主要关注点在于快速、灵活，能够提供大规模的数据响应。

常用的维度模型类型主要有：

1. 星型模型：即由一个事实表和一组维度表组成，每个维表都有一个维度作为主键。事实表居中，多个维表呈辐射状分布在四周，并与事实表关联，形成一个星型结构

2. 雪花模型：在星型模型的基础上，基于范式理论进一步层次化，将某些维表扩展成事实表，最终形成雪花状结构

3. 星系模型：基于多个事实表，共享一些维度表

4.数据漂移如何解决

什么是数据漂移？

通常是指ods表的同一个业务日期数据中包含了前一天或后一天凌晨附近的数据或者丢失当天变更的数据，这种现象就叫做漂移，且在大部分公司中都会遇到的场景。

如何解决数据漂移问题？

通常有两种解决方案：

1. 多获取后一天的数据，保障数据只多不少

2. 通过多个时间戳字段来限制时间获取相对准确的数据

第一种方案比较暴力，这里不做过多解释，主要来讲解一下第二种解决方案。（首先这种解决方案在大数据之路这本书有体现）

以下内容为该书的描述：

通常，时间戳字段分为四类：

1. 数据库表中用来标识数据记录更新时间的时间戳字段（假设这类字段叫 modified time ）

2. 数据库日志中用来标识数据记录更新时间的时间戳字段·（假设这类宇段叫 log_time）

3. 数据库表中用来记录具体业务过程发生时间的时间戳字段 （假设这类字段叫 proc_time）

4. 标识数据记录被抽取到时间的时间戳字段（假设这类字段extract time）

理论上这几个时间应该是一致的，但往往会出现差异，造成的原因可能为：

1. 数据抽取需要一定的时间，extract_time往往晚于前三个时间

2. 业务系统手动改动数据并未更新modfied_time

3. 网络或系统压力问题，log_time或modified_time晚于proc_time

通常都是根据以上的某几个字段来切分ODS表，这就产生了数据漂移。具体场景如下：

1. 根据extract_time进行同步

2. 根据modified_time进行限制同步， 在实际生产中这种情况最常见，但是往往会发生不更新 modified time 而导致的数据遗漏，或者凌晨时间产生的数据记录漂移到后天 。由于网络或者系统压力问题， log_time 会晚proc_time ，从而导致凌晨时间产生的数据记录漂移到后一天。

3. 根据proc_time来限制，会违背ods和业务库保持一致的原则，因为仅仅根据proc_time来限制，会遗漏很多其他过程的变化

那么该书籍中提到的第二种解决方案：

1. 首先通过log_time多同步前一天最后15分钟和后一天凌晨开始15分钟的数据，然后用modified_time过滤非当天的数据，这样确保数据不会因为系统问题被遗漏

2. 然后根据log_time获取后一天15分钟的数据，基于这部分数据，按照主键根据log_time做升序排序，那么第一条数据也就是最接近当天记录变化的

3. 最后将前两步的数据做全外连接，通过限制业务时间proc_time来获取想要的数据

5.拉链表如何设计，拉链表出现数据回滚的需求怎么解决

拉链表使用的场景：

1. 数据量大，且表中部分字段会更新，比如用户地址、产品描述信息、订单状态等等

2. 需要查看某一个时间段的历史快照信息

3. 变化比例和频率不是很大

  1--拉链表实现
  2--原始数据
  3CREATE TABLE wedw_tmp.tmp_orders (
  4    orderid INT,
  5    createtime STRING,
  6    modifiedtime STRING,
  7    status STRING
  8) stored AS textfile;
  9
 10--拉链表
 11CREATE TABLE wedw_tmp.tmp_orders_dz(
 12    orderid int,
 13    createtime STRING,
 14    modifiedtime STRING,
 15    status STRING,
 16    link_start_date string,
 17    link_end_date string
 18) stored AS textfile;
 19
 20--更新表
 21CREATE TABLE wedw_tmp.tmp_orders_update(
 22    orderid INT,
 23    createtime STRING,
 24    modifiedtime STRING,
 25    status STRING
 26) stored AS textfile;
 27
 28--插入原始数据
 29insert overwrite table  wedw_tmp.tmp_orders
 30select 1,"2015-08-18","2015-08-18","创建"
 31union all 
 32select 2,"2015-08-18","2015-08-18","创建"
 33union all
 34select 3,"2015-08-19","2015-08-21","支付"
 35union all
 36select 4,"2015-08-19","2015-08-21","完成"
 37union all 
 38select 5,"2015-08-19","2015-08-20","支付"
 39union all 
 40select 6,"2015-08-20","2015-08-20","创建"
 41union all 
 42select 7,"2015-08-20","2015-08-21","支付"
 43
 44--拉链表初始化
 45insert into  wedw_tmp.tmp_orders_dz
 46select *,createtime,'9999-12-31' 
 47from  wedw_tmp.tmp_orders
 48
 49--增量数据
 50insert into  wedw_tmp.tmp_orders_update
 51select 3,"2015-08-19","2015-08-21","支付"
 52union all 
 53select 4,"2015-08-19","2015-08-21","完成"
 54union all 
 55select 7,"2015-08-20","2015-08-21","支付"
 56union all 
 57select 8,"2015-08-21","2015-08-21","创建" 
 58
 59--更新拉链表
 60insert overwrite table  wedw_tmp.tmp_orders_dz
 61select 
 62    t1.orderid,
 63    t1.createtime,
 64    t1.modifiedtime,
 65    t1.status,
 66    t1.link_start_date,
 67    case when t1.link_end_date='9999-12-31' and t2.orderid is not null then '2015-08-20'
 68    else t1.link_end_date
 69    end as link_end_date
 70from  wedw_tmp.tmp_orders_dz t1
 71left join wedw_tmp.tmp_orders_update t2
 72on t1.orderid = t2.orderid
 73union all 
 74select 
 75  orderid,
 76  createtime,
 77  modifiedtime,
 78  status,
 79  '2015-08-21' as link_start_date,
 80  '9999-12-31' as link_end_date
 81from wedw_tmp.tmp_orders_update
 82
 83--拉链表回滚，比如在插入2015-08-22的数据后，
 84-- 回滚2015-08-21的数据，使拉链表与2015-08-20的一致
 85-- 具体操作过程如下
 86select 
 87  orderid,
 88  createtime,
 89  modifiedtime,
 90  status,
 91  link_start_date,
 92  link_end_date
 93from wedw_tmp.tmp_orders_dz
 94where link_end_date<'2015-08-20'
 95union all 
 96select 
 97  orderid,
 98  createtime,
 99  modifiedtime,
100  status,
101  link_start_date,
102  '9999-12-31'
103from wedw_tmp.tmp_orders_dz
104where link_end_date='2015-08-20'
105union all 
106select 
107  orderid,
108  createtime,
109  modifiedtime,
110  status,
111  link_start_date,
112  '9999-12-31'
113from wedw_tmp.tmp_orders_dz
114where link_start_date<'2020-08-21' and  link_end_date>='2015-08-21'

6.sql里面on和where有区别吗

数据库在通过连接两张或多张表来返回记录时，都会生成一张中间的临时表

以 LEFT JOIN 为例：在使用 LEFT JOIN 时，ON 和 WHERE 过滤条件的区别如下：

on 条件是在生成临时表时使用的条件，它不管 on 中的条件是否为真，都会返回左边表中的记录

where 条件是在临时表生成好后，再对临时表进行过滤的条件。这时已经没有 left join 的含义（必须返回左边表的记录）了，条件不为真的就全部过滤掉。

7.公共层和数据集市层的区别和特点

公共维度模型层(CDM):

又细分为dwd层和dws层，主要存放明细事实数据、维表数据以及公共指标汇总数据，其中明细事实数据、维表数据一般是根据ods层数据加工生成的，公共指标汇总数据一般是基于维表和明细事实数据加工生成的。

采用维度模型方法作为理论基础，更多采用一些维度退化的手段，将维度退化到事实表中，减少事实表和维度表之间的关联。同时在汇总层，加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

其主要功能：

1. 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据 扫描

2. 公共指标统一加工：基于 OneData 体系构建命名规范、口径一致 和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标建立逻辑汇总宽表

3. 建立一致性维度：建立一致的数据分析维表，降低数据计算口径、 算法不统一的风险。应用数据层（ ADS）：存放数据产品个性化的统计指标数据，根据 CDM 层与 ODS 层加工生成

数据集市(Data Mart):

就是满足特定部门或者用户的需求，按照多维方式存储。面向决策分析的数据立方体

8.从原理上说一下mpp和mr的区别

MPP 为并行数据库 ：

它的思路简单粗暴,把数据分块,交给不同节点储存, 查询的时候各块的节点有独立的计算资源分别处理,然后汇总到一个leader node(又叫control node),具体的优化和传统的关系型数据库很相似,涉及到了索引,统计信息等概念. MPP有shared everything /Disk / Nothing之别.

MapReduce其实就是二分查找的一个逆过程,不过因为计算节点有限,所以map和reduce前都预先有一个分区的步骤.二分查找要求数据是排序好的,所以Map Reduce之间会有一个shuffle的过程对Map的结果排序. Reduce的输入是排好序的 .

区别：

1. 底层数据库：MPP跑的是SQL,而Hadoop底层处理是MapReduce程序

2. 扩展程度：MPP虽然是宣称可以横向扩展Scale OUT，但是这种扩展一般是扩展到100左右，而Hadoop一般可以扩展1000+ ；因为MPP始终还是DB,一定要考虑到C(Consistency),其次考虑A(Availability),最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的，所以数据都是以文件存储，所以有限考虑的是P,然后是A,最后再考虑C.所以后者的可靠型当然好于前者

本质mpp还是数据库，需要优先考虑C(数据一致性)，而mr首先考虑的是P(分区容错性)；关于CAP理论可见十分钟搞定分布式一致性算法

9.Kimball和Inmon的相同和不同

Inmon模型：

流程：自顶向下，即从分散异构的数据源-->数据仓库---->数据集市。是一种瀑布流开发方法。模型偏向于3NF
数据源往往是异构的，比如爬虫；数据源是根据最终目标自行定制的。

这里主要的处理工作集中在对异构数据进行清洗，否则无法从stage层直接输出到dm层，必须先通过etl将数据进行清洗后放入dw层。

Inmon模式下，不强调事实表和维度表的概念，因为数据源变化可能性较大，更加强调的是数据的清洗工作，从中抽取实体-关系Inmon是以数据源头为导向，具体流程如下：

1. 首先探索获取尽量符合预期的数据，尝试将数据按照预期划分不同的表需求

2. 明确数据清洗规则后将各个任务通过etl由stage层转化到dm层，这里dm层通常涉及到较多的UDF开发，将数据抽象为实体-关系模型

3. 完成dm数据治理后，可以将数据输出到数据集市中做基本数据组合，最后输出到BI系统辅助具体业务

一般这种模型构建属于细水长流型的，而且技能/数据要求比较高，有可能有一天公司倒闭了，数仓还没有建设好

Kimball模型是以需求为导向

流程：自下向上， 即从数据集市-> 数据仓库 -> 分散异构的数据源 ，相当于是以最终任务为导向的；模型使用星型、雪花

1. 首先得到数据后需要先做数据的探索，尝试将数据按照目标拆分出不同的表需求

2. 明确数据依赖后将各个任务再通过etl由stage层转化到DM层。DM层由若干事实表和维度表组成

3. 完成DM层的事实表和维度表拆分后，数据集市一侧可以直接向BI环节输出数据

Kimball往往意味着快速交付，敏捷交付，不会对数仓架构做过多复杂的设计

特征对比：

10.MOLAP ROLAP HOLAP的区别和联系

MOLAP：多维联机分析处理，预计算

ROLAP：关系型联机分析处理， 依赖于操作存储在关系型数据库中的数据.本质上，每个slicing或dicing功能和SQL语句中"WHERE"子句的功能是一样的。

HOLAP：混合型联机分析处理（指的是MOLAP和ROLAP的结合）

11.埋点的码表如何设计

12.数据倾斜

13.group by 为什么要排序

14.缓慢变化维的处理方式

缓慢变化维(Slowly Changing Dimensions) 指的是维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。比如像我们的工作经历就是属于缓慢变化的。一般针对这种变化信息处理有10种处理方式。

1. 保留原值

   通常这种方式比较关注原始数据，比如原始的信用卡积分或者日期维度；需要对原始数据进行分析的场景下使用

2. 重写覆盖

   即修改属性值为最新值，即只关心最新的变化，需要注意的是如果涉及到olap，可能会进行重复计算

3. 增加新行

   通过追加新行的方式，需要注意的是和事实表的关联更新，即维度主键不能使用自然键或持久键，否则会出现数据发散。通常采用该种方式还需要增加几个附加列，如该行的有效时间和截止时间，以及当前行标示，这里可以通过拉链表来借助理解。

4. 增加新属性列

   基于维表来增加新的属性列来保留历史属性值。一般不常用。

5. 增加微型维度

   当维表中的部分属性出现快速变化的时候，可以使用该种方式，即将部分相对快速变化的属性从当前维表中划分出来，构建单独的微型维度表。

6. 微型维度结合直接覆盖形成支架表

   在第5种方式的基础上再结合直接覆盖的方式。即建立微型维表后，微型维度的主键不仅作为事实表的外键，而且也是主维度的外键。当微型维度表的属性值发生变化的时候，直接进行覆盖。

7. 同时增加行列，重写新加入的维度列

   这种方式的处理场景不常用，这里给出具体的样例配合理解。请注意截图标注的部分

1. 快照

这种方式比较粗暴，即每天保留全量的快照数据，通过空间换时间

1. 历史拉链

拉链表的处理方式，即通过时间标示当前有效记录

1. 双重外键结合直接覆盖和追加的方式

基于追加新行的方式上，使用双键来区别历史/当前属性。通过代理键获取当前记录，使用自然键获取历史记录。也是通过样例配合理解

参考资料：https://blog.csdn.net/qq_36039236/article/details/107819326

15.hive常见的优化思路

这里一般分为技术优化和业务优化。

技术优化根据hive底层的执行引擎不同采用不同的方式，但其思路都是一样的。

一般都是从存储、计算两个方面入手。常见的就是倾斜优化，存储优化则考虑是否选用压缩，以及使用哪种压缩方式，而计算则一般通过参数调优，如果以上两个角度都没有优化的效果，则需要考虑整体链路的优化，是否改用其他的技术方案。

业务优化这里其实比较抽象，一般都是逻辑的优化，即是否可以通过其他的业务角度来实现，这里简单举个例子，比如要统计上线用户数，那么是否可以通过统计下线用户数来反向统计呢？

其实优化涉及的地方比较多，这里先简单说一下思路，后面会有单独篇幅来讲解这块内容

16.数据质量/元数据管理/指标体系建设/数据驱动

注意：16～18题内容属于高级部分,笔者计划通过单独篇幅来讲解

数据质量涉及到数据质控，然后反作用于业务/技术产生闭环，这块并非单独一个人或一个部门就能解决的，一般都是从集团层面出发。

元数据管理这块内容可见元数据管理-技术元数据解决方案

指标体系建设和数据质量建设是同样的，并非个人能实现，主要是为了保证指标一致性。

17.如何保证数据质量

同第16道题一样

18.如何保证指标一致性

同第16题一样

19.Hive row_number，rank两个函数的区别

20.Hive窗口函数怎么设置窗口大小

首先需要理解什么是窗口函数？

这个跟flink的窗口是一样的，即函数在当前行上下多少行内进行计算，而这个行数是根据窗口大小来决定的。这里要跟聚合函数区分开来。

窗口函数：对于组内的每一行记录都会有对应的返回值

聚合函数：对于每个组分别返回一条记录

而窗口大小是通过over()方法来实现的.说到这里应该大部分读者就知道怎么回事了。如之前的数仓利器-Hive高频函数合集文章就有相关例子了。这里要说一下over的语法.

1开窗函数() over(partition by 分组字段 order by 排序字段 rows between current row|UNBOUNDED PRECEDING|num PRECEDING and current row|num FOLLOWING|UNBOUNDED FOLLOWING)

 

这里主要说一下 current row ,preceding,following这几个关键词：

current row:表示当前行

UNBOUNDED PRECEDING：表示从组内的起点开始

num PRECEDING:表示从当前行的前num行开始

num FOLLOWING：表示截止到当前行的后num行

UNBOUNDED FOLLOWING:表示截止到组内的最后一行

这里只给出使用样例，根据调整上面的参数最后得到的结果会跟lag,lead函数是一样的

 1select 
 2sum(cnt) over() as all_cnt,--所有行相加
 3
 4sum(cnt) over(partition by url) as url_cnt,--按url分组，组内数据相加
 5
 6sum(cnt) over(partition by url order by visit_time) as url_visit_asc_cnt,--按url分组，按照visit_time升序,组内数据累加
 7
 8sum(cnt) over(partition by url order by visit_time rows between UNBOUNDED PRECEDING and current row ) as url_cnt_1 ,--和sample3一样,由起点到当前行的聚合
 9
10sum(cnt) over(partition by url order by visit_time rows between 1 PRECEDING and current row) as url_cnt_2, --当前行和前面一行做聚合
11
12sum(cnt) over(partition by url order by visit_time rows between 1 PRECEDING AND 1 FOLLOWING ) as url_cnt_3,--当前行和前边一行及后面一行
13
14sum(cnt) over(partition by url order by visit_time rows between current row and UNBOUNDED FOLLOWING ) as url_cnt_4 --当前行及后面所有行
15
16from wedw_dwd.log;

21.Hive 四个by的区别

1. order by

   按照指定的key进行全局分组排序，且排序是全局有序的

2. distributed by

   distribute by 是控制map的输出在reducer端是如何划分的.hive会根据distribute by 后面指定的列，对应reducer的个数进行分发.默认采用hash算法.sort by 为每一个reduce产生一个排序文件.在有些情况下，你需要控制某个特定行应该到哪个reducer，这通常是为了进行后续的聚集操作。distribute by刚好可以做这件事。因此，distribute by经常和sort by配合使用.

3. sort by

   不是全局有序的，每个reduce端是有序的， 保证了局部有序 ；当只有一个reduce的时候，是可以实现全局有序的

4. cluster by

   是distirbuted by 和sort by 的结合，但是不能指定排序为asc或desc的规则，只能升序排列

22.Hive的udf、udaf和udtf了解吗？自己有没有写过

这里三者之间的区别，具体demo大家可自行练习，比较简单

UDF: User-Defined-Function 自定义函数

操作单个数据行，产生单个数据行

UDAF:User- Defined Aggregation Funcation；用户定义聚合函数

操作多个数据行，产生一个数据行 ;等同与SQL中常用的SUM()，AVG()，也是聚合函数；

UDTF: User-defined Table Generating Function

操作一个数据行，产生多个数据行一个表作为输出

23.怎么验证Hive SQL的正确性

笔者认为如果只是校验sql的语法正确性，可以通过explain或者执行一下就可以。

如果是校验sql的结果正确性，这个需要结合具体的业务来推算排查了

24.数据怎么同步到数仓的，怎么保证数据不丢失

首先数据同步根据读者使用情况来说明，而如何保证数据不丢失，笔者认为需要从以下3个方面来着手(其实就是从事前、事中、事后全方面考虑)

1.同步工具(事前)

目前主流的数据同步工具是sqoop、datax、canal、flume等。需要结合同步工具以及待同步的数据特性保证数据采集，例如使用sqoop来增量同步业务数据，这里需要保证业务数据中需要有更新时间，而且该更新时间是真的会进行更新(有时开发同学可能会忘记更新该时间的或者直接就是没有更新时间)。

2.平台稳定性(事中)

数据同步需要借助于调度系统，而且同步工具也有可能是直接集成到平台上，那么这个时候就需要保证调度和平台的稳定性。否则系统挂了还没有告警机制，那么就悲催了

3.监测机制(事后)

这里涉及到数据稽核了，即下游任务配置对应的稽核规则，当数据量波动超出阈值则需要发出告警，相关负责人就需要进行检查了。

以上是笔者个人的思路，描述可能不太全面或者准确，如果读者有更好的想法请及时联系笔者进行更改

25.Hive数据选择的什么压缩格式

hive支持的存储格式有TEXTFILE 、SEQUENCEFILE、ORC、PARQUET

压缩格式	算法	文件扩展名	是否可切分	对应的编码/解码器
DEFLATE	DEFLATE	.deflate	否	org.apache.hadoop.io.compress.DefaultCodec
Gzip	DEFLATE	.gz	否	org.apache.hadoop.io.compress.GzipCodec
bzip2	bzip2	.bz2	是	org.apache.hadoop.io.compress.BZip2Codec
LZO	LZO	.lzo	是	com.hadoop.compression.lzo.LzopCodec
Snappy	Snappy	.snappy	否	org.apache.hadoop.io.compress.SnappyCodec

压缩算法	原始文件大小	压缩文件大小	压缩速度	解压速度
gzip	8.3GB	1.8GB	17.5MB/s	58MB/s
bzip2	8.3GB	1.1GB	2.4MB/s	9.5MB/s
LZO	8.3GB	2.9GB	49.3MB/s	74.6MB/s

参数	默认值	阶段
io.compression.codecs （在core-site.xml中配置）	org.apache.hadoop.io.compress.DefaultCodec, org.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.BZip2Codec, org.apache.hadoop.io.compress.Lz4Codec	输入压缩
mapreduce.map.output.compress	false	mapper输出
mapreduce.map.output.compress.codec	org.apache.hadoop.io.compress.DefaultCodec	mapper输出
mapreduce.output.fileoutputformat.compress	false	reducer输出
mapreduce.output.fileoutputformat.compress.codec	org.apache.hadoop.io.compress. DefaultCodec	reducer输出
mapreduce.output.fileoutputformat.compress.type	RECORD	reducer输出

26.Hive SQL如何转化MR任务

和第28题大同小异

HiveSQL ->AST(抽象语法树) -> QB(查询块) ->OperatorTree（操作树）->优化后的操作树->mapreduce任务树->优化后的mapreduce任务树

27.lateral view explode关键词怎么拆分数组

lateral view通常和split,explode等udtf配合来使用，能够把一行数据拆分为多行数据。在此基础上可以对拆分后的数据进行聚合。

这里需要分别对latera view 和explode进行拆分讲解。

explode()：

作用：是将一行数据转成列数据，用于array和map类型的数据。

局限性：不能关联原有的表中的其他字段，不能和udtf嵌套使用

lateral view：

作用：为原始表的每行调用udtf,udtf会把一行数据拆分为多行，lateral view再把结果组合，产生一个支持别名的虚拟表，这样就解决了explode不能关联原有表其他字段的问题

原始数据见下图

使用explode()函数见下图

结合lateral view 使用结果见下图：

28.join操作底层的MapReduce是怎么执行的

根据join对应的key进行分区shuffle，然后执行mapreduce那套流程。关于mr的流程后面会有单独的hadoop专题进行讲解(这里读者可以先有个大致思路)

29.Hive map,reduce数怎么设置

30.Parquet数据格式内部结构

31.Hive分桶

今天的分享就到这里，谢谢大家。

分享、点赞、在看，人间真爱~

往期推荐

▼ 福利时刻 ▼ 

01. 文末扫码后台回复「经典」,即可领取大数据数仓经典书籍。

02. 文末扫码后台回复「中台」,即可领取大厂中台架构高清ppt。

03.文末扫码后台回复关键词：画像源码、画像ppt、用户画像，都可获取宝贵干货资源与资料

04.更多福利：

关键词	领取资源
ck安装	clickhouse安装pdf文档
0808	大厂实时数仓PPT合集
画像源码	用户画像项目源码
推荐系统	推荐系统教程视频
OneData	阿里OneData体系PPT

Q: 关于数据仓库，你还想了解什么？

欢迎关注我们一起进步

觉得不错，请把这篇文章分享给你的朋友哦

投稿请联系小助手：iom1128『紫霞仙子』

  

！关注不迷路~ 各种福利、资源定期分享！

[在看、收藏、转发]，真爱三连！